Add data points for Chrome 137 WebGPU additions

[chrisdavidmills]

Summary

Chrome 137 supports the following WebGPU updates:

• When using copyBufferToBuffer(), you can omit the offsets and the size parameter when copying the entire buffer. See https://developer.chrome.com/blog/new-in-webgpu-137?hl=en#buffers_copy_without_specifying_offsets_and_size.
• When creating a GPUBindGroup using createBindGroup(), you can specify a GPUTextureView in place of a GPUExternalTexture. See https://developer.chrome.com/blog/new-in-webgpu-137?hl=en#use_texture_view_for_externaltexture_binding

This PR adds data point for both those features.

Test results and supporting details

• Spec PR: copyBufferToBuffer: make offsets and sizes optional gpuweb/gpuweb#5098

Related issues

[github-actions]

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

[chrisdavidmills]

Thanks, @caugner, your changes look good.

[caugner]

Second thoughts:

[caugner]

It looks we usually prefer a more general wording "accepts_X" when it comes to parameters or options accepting a certain type.

Also, we're actually talking about the resource field (of type GPUBindingResource), which is provided via the entries option (a GPUBindGroupEntry sequence), which is passed to createBindGroup() via the (only) descriptor parameter (a GPUBindGroupDescriptor). So bind_GPUTextureView skips all these intermediate levels.

Note also that the GPUBindingResource type includes more than GPUTextureView and GPUExternalTexture, so the question arises whether these other types are currently supported or not?

Assuming we go with the currently proposed structure, then I would also expect a subfeature bind_GPUExternalTexture, and possibly more in the future.

Alternatives are:

• Making the feature id more explicit (e.g. descriptor_entries_option_accepts_GPUTextureView_resource).
• Adding an intermediate subfeature for the descriptor_entries_option, either with partial_implementation as long as all types aren't implemented, or with subfeatures accepts_GPUTextureView_resource.

@chrisdavidmills Wdyt?

[chrisdavidmills]

Impressive bit of analysis there, @caugner. What you are saying sounds correct, but I worry that we are in danger of making the data hard to understand. I was more going for describing the end result (we can now bind GPUTextureViews) rather than the exact dictionary option chain required to make this result happen.

The other possible resources to bind are all supported, so I thought it would be OK to omit those.

Out of these two options, I'd prefer the first alternative. Because we mostly don't tend to create separate page trees for every dictionary, we don't usually end up with separate BCD for each one either.

[caugner]

Okay, I actually missed that this was a spec change, so it absolutely makes sense to only document this type.

So let's go with the first alternative, making the feature id more explicit. I don't think we have guidelines for the description, so I'm okay with keeping the current one.

[chrisdavidmills]

done

[caugner]

Thanks!